home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
EuroCD 3
/
EuroCD 3.iso
/
Communication
/
Citadel_BBS
/
Docs
/
UTIL3.man
< prev
next >
Wrap
Text File
|
1998-06-24
|
46KB
|
1,260 lines
C I T A D E L - 8 6
V3.40
UTILITIES MANUAL
Copyright 1989 - 1991
by Hue, Jr.
C-86 Test System Sysop
91Sep15
TABLE OF CONTENTS
History . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
Clog.exe . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Clray.exe . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Recover1.exe . . . . . . . . . . . . . . . . . . . . . . . . 3
Expand.exe . . . . . . . . . . . . . . . . . . . . . . . . . 4
Recover2.exe . . . . . . . . . . . . . . . . . . . . . . . . 4
DataChng.exe . . . . . . . . . . . . . . . . . . . . . . . . 5
Logedit.exe . . . . . . . . . . . . . . . . . . . . . . . . . 5
Popular.exe . . . . . . . . . . . . . . . . . . . . . . . . . 6
Culldir.exe . . . . . . . . . . . . . . . . . . . . . . . . . 6
Nodelist.exe . . . . . . . . . . . . . . . . . . . . . . . . 7
MsgAdd.exe . . . . . . . . . . . . . . . . . . . . . . . . . 7
MsgOut.exe . . . . . . . . . . . . . . . . . . . . . . . . . 8
Clean.Exe . . . . . . . . . . . . . . . . . . . . . . . . . . 8
VirtAdmn.Exe . . . . . . . . . . . . . . . . . . . . . . . . 9
RoutMail.Exe . . . . . . . . . . . . . . . . . . . . . . . . 9
Screen.Exe . . . . . . . . . . . . . . . . . . . . . . . . . 16
Ease.Exe . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Aff.Exe . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Vexfind.exe . . . . . . . . . . . . . . . . . . . . . . . . . 18
-1-
History
The following is a chronological chart of the history of the updates
of the C-86 utilities.
91Mar31 HAW MsgAdd and MsgOut updated for Virtual Rooms.
90May HAW Aff; update RoutMail with +domains.
89Jun22 HAW Ease.
89Apr17 HAW Version 2 of LogEdit.
89Feb26 HAW Major Release update(3.16): Clean, RoutMail, VirtAdmn, Screen.
88Dec19 HAW MsgAdd, MsgOut; general cleanup.
88Jan04 HAW Culldir, Nodelist, and Loadshar detailed. Lexpand deleted.
87Oct16 HAW V3 of Citadel-86 update.
86Apr08 HAW Version 2 of Popular detailed.
86Apr01 HAW Popular detailed.
85Aug25 HAW Ctdlchng expanded.
85Aug10 HAW Logedit detailed.
85May25 HAW Lexpand detailed.
85Apr25 HAW Reviewed for MS-DOS conversion.
85Feb18 HAW Recover2 detailed.
84Dec09 HAW Expand changed.
84Jun29 HAW Ctdlchng detailed.
84Jun28 HAW Expand detailed.
84Jun27 HAW Recover1 detailed.
84Jun26 HAW Clray detailed.
84Jun26 HAW Created. Clog detailed.
Introduction
Since the days of yore when we received Citadel from CUG (C User's
Group), several utilities of interest have been added to the package to
supplement the original two .com files that came with the package, to wit
CITADEL.COM and CONFIGUR.COM. These come in two types: one, to provide
information about what's going on inside this monster which, due to
runtime space considerations, could not be gotten at; two, the ability to
change certain parameters which were either impossible to change once a
BBS was set up, or were, at the least, difficult to change.
The descriptions (such as they are) follow herein!
Clog.exe
Clog provides access to the userlog for the Sysop. To use it, the file
CTDLTABL.SYS (the one generated by CONFG and maintained by CTDL.EXE)
must be on the default disk, and so must be CTDLLOG.SYS.
There are two ways of using Clog. First, there is the simple call:
D>CLOG
This will print out on the console the list of users in the file as they
appear in the file. The user of this program should be warned that
Citadel does not put new users into the userlog in sequential order.
Instead, they are hashed into the log. Usually, first user to log into
the system ends up occupying the last position in the file! In general,
users are sprinkled everywhere, so don't be alarmed if nothing shows up
right away. Be patient.
-2-
In any case, the list is printed out as follows. First, the log
position will be printed out, which will always be in sequential order.
If nobody occupies that position, then Clog proceeds to the next log
position. If somebody does occupy that position, then the name of that
person (or alias) will be printed out, followed by his/her status as
aide, expert/non-expert, screen width, and if they have net privileges
the entry will be followed by a 'N'.
The second way to use Clog is to give it arguments. There are two
arguments currently available in the MS-DOS version. The first is the
-P argument:
D>CLOG -P
This will cause the passwords to be listed along with the user's name.
This is useful if somebody forgets their password. The second argument
is a user's name. When a user's name appears on the command line, then
data for that account only will be shown. You may use -P and a user's
name on the same command line.
If, for some reason, the sysop wants a list to be put out to a file,
use the MS-DOS re-direction commands. If you want the list to be put out
to the file LOG.LST, the type
D>CLOG >LOG.LST
Naturally, the -P argument may still be used when re-directing output.
Clray.exe
Clray.exe is another program used to view the userlog. As before,
CTDLTABL.SYS must be on the default disk in the root directory, as must
CTDLLOG.SYS. There are currently no arguments for Clray.
Clray's purpose is to allow the sysop to see what order the users have
been calling in, starting with the last caller. Along with the users
name, his/her aide status, column width, and expert status will be
printed, as in Clog.
Simply call Clray to run it. Output redirection may be used as in CLOG.
Recover1.exe
Occasionally, a room may be killed by accident by an aide. Or worse,
a Village Idiot will break an aide's password, and then kill rooms which
the Sysop thinks has socially redeeming value. It is at this point that
Recover1 may be of use.
Recover1 may only be used if the following applies -- rooms have been
killed, but no rooms have been created. If a room(s) has been created,
it may have overwritten the old data. Rooms which weren't overwritten can
still be saved of course. If new rooms have been created, Recover2.exe
should be used.
-3-
To use Recover1, the system should be setup as normal. Simply call
Recover1. It will read in CTDLTABL.SYS. Then it will start looking at
the rooms as found in CTDLTABL.SYS. When it finds evidence that a room
has been killed, it will printout on the screen the name of the room, and
ask the Sysop if s/he wants Recover1 to try to save the room. If it
receives an upper or lower case Y, then it will do so. Currently, there
is no reason known why it shouldn't succeed.
When finished it will announce so and replace CTDLTABL.SYS with the
updated version, and then leave. However, hopefully you'll never need
this program.
Expand.exe
Expand's purpose in life is to allow the sysop to expand the size of
his/her message file (CTDLMSG.SYS). This makes it easy to move upwards
as one gets rich running Citadel for cold, hard cash and acquires better
and better equipment.
Expand expects to the system to be in its normal setup. Simply call
Expand without arguments. Once it has loaded CTDLTABL.SYS, it will
display the current size of the message file, and then ask for the new
size. Answer in Kbytes. Now Expand will do it's job. THIS IS A SLOW
PROCESS. Be patient. The program will be printing some stuff out that
might allow the sysop to figure out where the program is.
Once the program is done, it will say so, and will also tell you that
there is no reason to reconfigure. This is true.
Recover2.exe
Recover2.exe is to be used in the extreme emergency of either A)
someone breaking an aide pwd and deleting rooms and then creating other
rooms, thus negating the utility of Recover1.exe, or B) the loss or
contamination of CTDLROOM.SYS.
Use of Recover2.exe really should be avoided. The effects of
Recover2.exe are:
* All <Z>Forgotten room lists are totally screwed up;
* Privacy status of rooms are lost and will have to be reset;
* Directory status of rooms are also lost and will have to be reset;
* Deleted messages will reappear in their rooms of origin;
* And so will inserted messages.
* Various other room privileges will be lost or screwed up.
* Everything will end up on the base floor.
Recover2.exe works by scanning the message file. Each message has
associated with it its room of origin, so the program is fairly simple.
However, it is also rather slow.
The system should setup as normal.
-4-
DataChng.exe
The purpose of the DataChng.exe utility is to give the sysop the
ability to non-destructively several CTDLCNFG.SYS parameters. The
relevant parameters are:
#MAXROOMS
#MSG-SLOTS
#MAIL-SLOTS
#LOGSIZE
#SHARED-ROOMS
#NET-ARCH-ROOMS
ALWAYS MAKE BACKUPS BEFORE USING THIS UTILITY!
DataChng is a very crude and simple menu-driven program which exits
when an illegal selection is made from the menu. On valid selections,
DataChng will ask for a new value, and then ATTEMPT to modify your
installation for the new value. NOTE: As of this writing, the system
attempts all changes IN MEMORY. If there is not enough RAM, then this
utility fails. This should only happen for very large installations
("large", in this case, does not refer to the message base; see
EXPAND.EXE for details on expanding your message base). If this happens
to you, then you should either attempt to hack the source for this
utility so that it uses temporary files (a tedious but simple procedure),
or entice someone into doing it for you (ibid).
With the exception of the LOGSIZE parameter, all of the parameters may
either be shrunk or expanded. LOGSIZE can only (currently) be expanded.
Make sure to update your CTDLCNFG.SYS after using DataChng.exe!
However, you do NOT need to use CONFG.EXE after using DataChng.exe.
Logedit.exe
LOGEDIT provides the ability to edit the user log offline. LOGEDIT
will act in one of two ways, depending on the machine your system is
configured for.
If the configuration is for a Zenith Z-100, LOGEDIT will be a simple,
very crude question and answer routine. The system will ask for an
account to kill, which you answer by NUMBER (use CLOG to find the
numbers you need). If you confirm the kill, the account is nuked.
If the configuration is for a PClone, LOGEDIT will be a visually
oriented utility. The account names will be listed; you may select
any by using the cursor keys. Touching the DEL key will cause the
current account to be nuked. Touching the carriage return will allow
you to view and edit the values of the account. Touching the ESC key
will end LOGEDIT.
The last action LOGEDIT performs is to digest the user log. Please
do not interrupt it during this task.
-5-
Popular.exe
The POPULAR utility is a statistics-gathering utility, and, as such,
can be easily viewed as your basic feeping creaturism. However, for those
of us who have somehow acquired that horrible taste for odd statistics
about how people use Citadel, it does serve some purpose.
POPULAR gathers statistics about the Public rooms on a system. These
statistics consist of simply calculating how many people have forgotten
each Public room on a system. Yes, a rather odd statistic to gather, but
there it is. Once it has finished processing the data, it displays the
results in tabular form, in (roughly) the following form:
<room name> <# of people who have forgotten this room> <% of total users>
To use this utility, simply make sure your data files are in their
normal drives, and run this program. The output of this program may be
redirected to a file via the MS-DOS ">" directive, although not all the
output will end up in the output file. Unimportant output will continue
to go to the screen; the important data will end up in the file you
designated.
There is one command line option available, "-M". If this option is on
the command line to Popular, it will also scan the message file, counting
the number of messages that originated in each room and performing AML
calculations on a per room basis, and display those values for each public
room in the same tabular format.
The rooms are displayed in descending order of how many people have
forgotten each room.
Culldir.exe
The Culldir utility is to be used in conjunction with active directory
rooms. Let's face it: while the FILEDIR.TXT/.RE option is real handy for
directory rooms, it's a real pain trying to keep FILEDIR.TXT culled of
files that no longer exist in the directory. That's what Culldir is for.
It will go through a FILEDIR.TXT and delete all entries in it for which
files do not exist in the current directory.
Usage is very simple. Place yourself in the DOS directory that has
a FILEDIR.TXT with extra entries in it, and run Culldir. It expects all
of the data that it will work on to be on the default drive, in the
current directory. If it doesn't find a FILEDIR.TXT, it will abort
operation. Culldir is unique amongst the utilities in that it doesn't
need any of the normal Citadel-86 data files -- only a directory with
FILEDIR.TXT in it.
-6-
Nodelist.exe
Nodelist is intended to help you maintain, in some slight way, your
netlist. There are two modes to Nodelist, with and without arguments.
When you run Nodelist without arguments, its output to the screen will
consist of a listing of shared rooms. Underneath each shared room will
be a list of the systems that you are sharing the room with, terminated
by a blank line. You may use DOS' redirection ability ('>') to place the
output in a file.
Using arguments with Nodelist will, of course, alter its behavior.
There are three arguments currently supported. The first is "-n". This
causes all the nodes on your nodelist that are not disabled to be listed.
The second argument is "-nd", and causes all nodes on your nodelist,
regardless of their status, to be listed. The third argument is "-s",
which causes each system on your nodelist that you share rooms with to
be listed, along with the rooms you share.
MsgAdd.exe
MsgAdd.exe is utility for use with programs which act as gateways
between Citadel-compatible systems and other (foreign) networks. Its
purpose is to allow the addition of messages to a Citadel-86 message
base. The 'typical' system operator will rarely have a use for this
utility.
The command line format of MsgAdd is
C>MsgAdd <node name> <file names>
The first argument, node name, should be the name of a node on
your nodelist, typically (although not always) a node which has been
designated OtherNet. The purpose of specifying a node name is to allow
correct routing address decisions to be made by MsgAdd, which will in
turn allow Citadel-86 to route messages from the foreign network to
other Citadel-86 systems.
There should be at least one file name following the node name. Each
file should contain at least one message from the foreign network in
C86Net message format (see NETHACK3.MAN for the complete specification).
Of all the fields that makes up a C86Net message, the following should
be filled in by the gateway program for each message:
Author
Date
Name of Origin System - need not be 'node name' in the command line
Node ID of Origin System - a matter for some thought
Room for message - a MUST
Recipient iff msg is private mail
Message Text
Attempting to add messages to rooms which are not shared with 'node
name' will result in warning messages, but the messages will be
inserted. By formally sharing rooms with 'node name' you ensure that
the companion utility to MsgAdd, MsgOut, will pick up messages for the
foreign net and speed them on their way.
-7-
There is one weakness in MsgAdd: it does not do vortex processing on
the messages from the foreign network. This is simply the result of a
lazy programmer. However, when dealing with virtual rooms, the Msgout
utility (detailed below) should always be run before the Msgadd utility
due to the way Citadel-86 remembers which messages still need to be
sent to other nodes.
MsgOut.exe
MsgOut is the reverse of the MsgAdd utility -- it will extract
messages from a Citadel-86 installation and write them to a file in
C86Net format, for later processing by a gateway program for insertion
into a foreign network. The 'typical' system operator will have little
to no use for this utility.
Command line format for MsgOut is
C>MsgOut <node name> <filename>
'node name' is the name of a node on your nodelist for which you
wish to extract messages, while 'filename' is the file to place all
such messages in, no matter what room they came from.
So, the question becomes, "What messages are extracted?" The answer
is conceptually simple: Think of 'node name', despite being a designation
of a foreign (OtherNet) network, as just another C86Net system. MsgOut
is then just like a normal network session. All messages which would
have been sent to this system during a normal network session, both
shared rooms and netMail, will be written to 'filename' in C86Net format.
The gateway program is then expected to digest 'filename' and pass
on those messages to the foreign network in the appropriate format.
MsgOut will handle virtual rooms, but always make sure MsgOut is
run before Msgadd; otherwise, MsgOut will not find and place in the
file all outgoing messages meant for the foreign network.
Clean.Exe
The Clean utility is an anti-ruggie utility. Occasionally, a ruggie
will gain access to your system and flood a favored room with messages of
negative social value. The most frustrating fact of this behavior is the
knowledge that the good messages which were scrolled out of the room are
still in the message base, but no longer accessible. This utility will
make them available.
Simply run Clean from the command line. Clean will prompt for a room
name, and then a list of names to 'clean' from the room (in case more
than one ruggie has attacked). Once you have typed in all names you wish
cleansed from the room, Clean will scan through your entire message base
for messages belonging to the named room. Those messages written by
users you designated will not be saved in the room any longer, while
those by users you did not name will be saved, thus recovering 'scrolled'
messages. Those messages cleansed will no longer be accessible (unless
you run Clean again on the same room and forget to name those users!).
Perhaps sometime in the future this utility will be modified to allow
cleansing an entire roombase of a user.
-8-
VirtAdmn.Exe
This utility is the Virtual Room Administrator for Citadel-86, and as
such is of interest only to backbones with heavy traffic. The motivation
and usefulness of VirtAdmn are explained in Section III.3.i of
Network3.Man.
VirtAdmn has two modes to it. The first mode, interactive, is
accessed by simply typing 'VirtAdmn' at the DOS command line. It will
place you in a primitive but adequate menu driven system which will let
you add, delete, and modify virtual rooms from your system.
The second mode is 'batch' mode. This mode is used to allow VirtAdmn
to delete 'virtual' messages from your system which are no longer needed,
that is, which have already been delivered to all eligible systems. We
suggest this be run fairly often to keep your disks from running out of
room, as some net rooms have fairly high traffic levels. Consider using
an external event to run Batch mode, possibly as part of an automated
backup procedure. Invocation of batch mode is by typing 'Virtadmn +batch'
at the command line.
There is one more option which may be used with VirtAdmn, in both the
interactive and batch modes, and that is the 'log' option. When used,
the results of the operation of VirtAdmn will be placed in your
NETLOG.SYS file. Simply add '+log' to the command line if you wish this
to occur.
RoutMail.Exe
This section of the Utilities manual documents the program RoutMail.Exe.
RoutMail.Exe handles the administrative side of the C86Net RouteMail
feature.
This is divided into two sections. The first section is of interest to
any sysop wishing to participate in C86Net RouteMail. The second section
is of additional interest to System Operators of backbone systems which
will be routing Mail for other systems.
Please note that with the release of V3.32, which can support
secondary node lists (see NETWORK3.MAN) that are updated automatically,
most sysops' only use for RoutMail will be the +manual option. Even the
major backbones (Domain Handlers) will have use, most of the time, only
for the '+domains' option (see below), along maybe with '+kill'.
GLOSSARY
HUB: A "HUB" node is any node which is willing to accept mail from one
node for delivery to another node. This may optionally not include nodes
for which such traffic is very light and irregular, but will apply to
heavily used backbones such as Utica College, Chaos II, AARDVARK!, KAOS,
Test System, etc.
PEON: A "PEON" node is a node which will carry very little or no netMail
from one node to another, but is more likely to simply send and receive
such netMail.
Section 1: C86Net RouteMail for everyone.
a) What is "RouteMail"? RouteMail is a feature of Citadel-86's C86Net
which allows systems to send netMail to other systems without calling
those systems directly.
-9-
b) How does it work internally? Briefly, any system will know how to
send netMail to any system on its nodelist. A), it'll call it directly,
or B) it will call some other node and ask it to pass the netMail on to
the target system. In the case of B), it's not impossible, and in fact
fairly normal, for this intermediate system to call yet another system in
order to pass the netMail onwards, and this can continue, step by step,
until it reaches its destination.
Three well-known systems of the net, for instance, are Chaos II in
Edmonton, Utica College (UCC) in Utica, NY, and Test System in the Twin
Cities of Minnesota. Test System talks to the other two on a nightly
basis, but UCC and Chaos II rarely talk to each other. Suppose Chaos II
wishes to send netMail to UCC. During its nightly talk to Test System, it
would ask Test System to take this netMail and send it to UCC. The next
time Test System talks to UCC, it would ask it to accept the Mail. If the
target was not UCC, but some system "beyond" UCC, it would in turn try to
pass it on to that system, given that Test System knew that in order to
get to this system beyond UCC, it should go via UCC. And etc.
c) So why RoutMail.Exe? To keep the main executables smaller. Since
you can run RoutMail as a local door, and possibly as a remote door, this
should not cause problems or inconvenience.
RUNNING ROUTMAIL
RoutMail can be run in one of two modes. The first mode is called
'automatic' mode, and the second mode is called 'manual'.
The purpose of automatic mode is to allow the sysop to update the
current netMail routes of C86Net on an automatic basis. When RoutMail is
run in this mode it will read a textfile describing the current C86Net
configuration and update your nodelist with it, subject to some control
on your part. Updating may include rerouting mail when a path to a node
becomes invalid and is replaced with another.
The generic command line of RoutMail in automatic mode is this:
C>RoutMail [options] <mapfile>
That is, the program followed by zero or more 'options' selections
followed by the name of the map file to be digested by RoutMail.
Your first question is probably, "What's this about a map??" The map,
as noted, is a textfile describing the current C86Net. The precise format
of the map is described in Section 2 (Advanced) of this file, and should
not be of concern to you unless you are a backbone likely to be involved
in the construction of the map, or enjoy abstruse details. A current map
should be available at all times from your local backbone (if you are not
a backbone), or from one of the major backbones of the net (if you are a
backbone and want a more uptodate map), possibly Arcadia in Michigan.
So now you'll want to know what these 'options' will do for you.
Options supported at the moment are
-10-
"+add": allows RoutMail to add all unknown nodes found in the map to your
nodelist. Such nodes will always be added as 1200 baud, non-local nodes
attached to net #15, under the assumption that most sysops will not be
using that net. If you don't use this option, then nodes you are not
aware of on the net will not be added to your nodelist. This will let you
keep your nodelist small. In fact, there's little use (with the release
of V3.32) for this option; most routing responsibilities will be taken
over by the domain handling options (see below).
"+kill": allows RoutMail to delete nodes from your nodelist which have
been designated in the map as "dead" nodes, that is, nodes which are
permanently off the network. If you don't use this option, any node
designated as dead will not be affected on your nodelist.
"+domains": this option lets the sysop add in to his primary node list
only those systems which are listed as Domain Handlers in his CtdlDmhd.Sys
file AND those systems via which, according to the routmail map which was
also present on the command line, you would use to get to those nodes.
This option is very useful to those systems which are already Domain
Handlers (since they are also usually backbones on the network, and
therefore need to know how to get to those other domain handlers). We
recommend Domain Handler sysops run RoutMail with the +domains option
and the latest RoutMail map whenever they receive a new CtdlDmhd.Sys from
their distribution point.
The second RoutMail mode is 'manual'. Manual mode allows you to carry
out RoutMail and other network administration (as a convenience) on nodes.
The command line for using RoutMail.Exe in manual mode is
C>RoutMail +manual
Your options vis a vis RoutMail and nodes are as follows:
o Accepting RouteMail from any given node (allows you to bar 'rogue'
Citadels from abusing your system)
o Accepting RouteMail for any given node (allows you to not accept netMail
for any given system)
Precise procedures for using RoutMail in manual mode should be
self-explanatory in the program prompts.
Miscellanea about C86Net RouteMail itself
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is not compatible with STadel mail routing. However, this only
applies to intermediate backbones; a target of a mail routing may be any
node which supports C86Net normal mail - the Citadel-86 doing the routing
will convert the mail to normal mail for the final relay to the target
node.
See NETWORK3.MAN on being a STadel gateway.
Section 2: Advanced - Map file structure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This section describes the structure of the map file. Since the map is
really all about systems, first we should specify how to put a system on
the map. The jargon we'll use is 'system identifier', and the format is
this:
<system node ID>:<system name> [@<baud>]
-11-
An example would be
US 612 470 9635 : Test System
and
US 612 470 9635 : Test System @2400
would also be valid.
Note that while the nodeId given must be the system's node id, the node
name doesn't necessarily have to match what that system uses for a
nodename. This alleviates problems with ridiculous names (such as TTWOL's
insistence on including its phone number in its nodename).
When entering data into a mapfile, only data starting at the left most
column is significant. Any line starting with one or more blanks is
considered a comment, not of use to RoutMail.
The general structure of the map is this
PEONS
<description of all hub->peons relationships>
HUBS
<description of all hub->hubs relationships>
CHANGES
<description of all changes to individual nodes>
DEAD
<listing of systems that were on the net which are now off>
COMMENTARY
<talk about the netmap, if any>
The PEONS / HUBS / DEAD /etc. titles allow RoutMail to identify what
the data is all about. We'll now go over the format of data for each
section in detail.
PEONS section
This section identifies which "hubs" talk to which "peons" directly.
As noted in the glossary, a "hub" node is a node which is willing to carry
a lot of netMail from one node to another node, while "peons" are nodes
which do not act, usually, as intermediaries between different nodes.
-12-
This section's format is a series of records, each record separated
from the next by a blank line. Each record is structured like this:
<hub identifier>
<peon identifier>
<peon identifier>
<peon identifier>
...
Each record contains one hub node, the first in the list, and all of
the peon nodes which it will service. No hub nodes should appear as peons
in these lists! For instance, one possible record would be
CA CA 403 433 2454 : Chaos II
CA CA 403 455 1701 : Quincunx
CA CA 403 426 1401 : Rock
which would detail all the peons Chaos II services. However, it would be
incorrect to add Test System to the bottom of that particular list,
because Test System will be serving as a hub. The relationship between
Test System and Chaos II is described in the HUBS section, since they are
both hubs. However, Test System would appear as the first member of
another list in the PEONS section, describing itself as a hub for systems
in the Twin Cities area.
While no hub may appear in any of the lists as anything other than a
hub, and then only once, a peon may appear in more than one hub's listing.
This is due to the reality that more than one hub may exist in an area,
such as the UCC/KAOS tandem. They don't overlap in their coverage, and so
provide the only (current) paths to certain nodes.
Note that while a hub must be able to carry C86Net route mail in order
to be a hub, a Peon does not have to be similarly capable in order to be a
Peon, thus allowing the attachment of STadels, C-68Ks, and other such
normal Mail> capable systems to the netmap. While such systems are
incapable of sending routed mail to other nodes, they may receive it.
HUBS section
This section serves to detail the hub configuration. The format is,
once again, a series of records, each a list of system identifiers
separated by blank lines.
In this case, each record begins with a hub identifier, and is followed
by one or more hub identifiers. The record serves as a definition of all
hubs which the first hub communicates directly with. For instance, the
listing for Chaos II would be
CA CA 403 433 2454 : Chaos II
US 612 470 9635 : Test System
[any other hubs Chaos II communicates directly with]
-13-
Each hub in the C86Net should appear as a 'first' node once, and only
once, listing each hub it communicates directly with. The implication is
a high level of redundancy occurs. To complete our above example, it
would be necessary that somewhere in the HUBS section an entry of the form
US 612 470 9635 : Test System
CA CA 403 433 2454 : Chaos II
[any other hubs Test System communicates directly with]
also appear. While the level of redundancy could undoubtedly be
reduced ... it ain't for the first version of RoutMail. Sorry.
CHANGES section
This section allows automatic changes of the nodelist by listing all
nodes which have changed IDs or (more rarely) names. The format in
this section differs from all others.
<old id> : <new id> : <name> [@baud]
is used for each node which has changed.
DEAD section
The format of the DEAD section of nodes is simply a list of system
identifiers.
COMMENTARY section
This section is functionally useless to RoutMail, and is ignored. It
can be used as a way to distribute news, instructions, or whatever strikes
the fancy of the mapmaker.
MAP EXAMPLE
The following is an example, based on our current situation, of a
possible net map. Note that it's incomplete, since I don't know the
situation of even the Twin Cities in complete detail, much less anywhere
else.
(* START OF EXAMPLE *)
This file contains an example description of a C86Net topology similar to
an actual situation, involving Edmonton, Alberta, the Twin Cities of
Minnesota, Kalamazoo, Michgan, and Utica, NY.
PEONS
This section covers Utica, NY. Note that Jersey Devil, while a backbone
for the shared rooms, is not route mail compatible and is thus a peon,
while KAOS, much closer to UCC, is a hub itself for THE_LAND, an STadel,
and thus not on UCC's peon list. Notice that since Swinger's is in the
area covered by both KAOS and UCC, it appears in both their lists.
US 315 792 3187 : Utica College
US 315 735-2058 : Swinger's Den
US 609 893 2152 : Jersey Devil
-14-
The land, being an STadel, is listed as a PEON, despite it being a main
backbone for the ST side of C86Net.
US 315 735 0545 : KAOS
US 513 254 6811 : THE_LAND
US 315 735-2058 : Swinger's Den
This section covers Kalamazoo, Michigan.
US 616 343 4136: Arcadia
US 616 349 5887:The Beach
US 616 381 3646:Secret Citadel
This section is for the Twin Cities.
US 612 470 9635 : Test System
US 612 429 5001 : Backfence
US (612) 431-4807 : Lumber Yard
US 612-938-8580 : New Eden
US 6124311107 : SuperComp III
This section is for Edmonton.
CA 403 433 2454 : Chaos II
CA 403 455 1701 : QuinCunx
HUBS
Now for the hub descriptions.
US 315 792 3187 : Utica College
US 315 735 0545 : KAOS
US 612 470 9635 : Test System
US 315 735 0545 : KAOS
US 315 792 3187 : Utica College
US 612 470 9635 : Test System
US 616 343 4136: Arcadia
CA 403 433 2454 : Chaos II
US 616 343 4136: Arcadia
US 612 470 9635 : Test System
CA 403 433 2454 : Chaos II
US 612 470 9635 : Test System
DEAD
For completeness, we add one node in here, a node that recently went away
in the Twin Cities. Note we skipped right over the CHANGES section.
US 612 425 0554 : Ivory Tower
COMMENTARY
And now for the news....
(* END OF EXAMPLE *)
-15-
Screen.Exe
Screen is a utility which allows easy modification of Citadel-86
sysConsole colors. Usage is simple, just type 'SCREEN'. You will then
be allowed to select colors for both the foreground and background as you
wish. Once you are satisfied with your selection, ESC will terminate the
program. If you ran Screen in your installation's main directory, Screen
will modify your CTDLTABL.SYS so that when you bring your system back up
the colors will be as you selected. However, it will not modify your
CTDLCNFG.SYS file for you. To help you do that, though, it will generate
a file named COLORS which will list your selections. The reason you want
to modify your CTDLCNFG.SYS is in case you have a crash or something
which forces you to reconfigure.
Screen will run equally well without a Citadel-86 installation, too.
It simply will not modify anything but the COLORS file it generates.
Ease.Exe
Ease is the Citadel-86 installation and modification utility for the
PC version of Citadel-86. It has two tasks, already implied: installation,
and modification (editing) your system.
In order to run effectively, Ease requires the files Ease.Hlp (which
should always accompany Ease.Lzh), Ease2.Hlp, Modems, and access to
Citadel-86's CONFG.EXE program.
Ease's abilities as an installation program should allow the creation
of a minimal, non-netting system by both the novice and experienced
sysops, including the creation of a useable CTDLCNFG.SYS.
Ease's abilities as the Citadel-86 modification program are extensive.
They include
o Enabling netting
o Editing all policy options
o Editing all file locations
o Modifying file sizes
o Video modifications
o #event editing
o #door editing
o etc
The abilities of the Citadel-86 utilities DataChng, Expand, and
Screen are completely contained in Ease, and Ease becomes the primary
Citadel-86 utility as of its release.
Aff.Exe
Aff, which stands for Automatic File Forwarding, is a Citadel-86
utility designed to simplify the job of automatically forwarding
files from one system to another with only some initial sysop
assistance.
-16-
The basic idea is there are certain files, updated from time to time,
which should be sent to some set of systems after each update.
(If this doesn't seem likely to you, then you probably have little
use for this utility.) By using the Aff utility in combination
with the Citadel-86 #event to bring your system down periodically
to run Aff, you can automate the process of sending said files to
other systems when they are updated.
Enough of the arm-waving. In order for this to work, you have to
tell Aff what you want sent, and where. You do this via a file you
construct named CTDLAFF.SYS, which will be located in your #NETAREA
directory. The structure of this file is:
<filename>
<system name> : 0
<system name> : 0
<system name> : 0
...
<blank line>
<filename>
<system name> : 0
<system name> : 0
<system name> : 0
The first line is the name of the file which will need to be sent
each time it's updated. There is one trick to this "filename" -- while
you create the file in #NETAREA, you run the Aff utility from the same
place you run Ctdl, and therefore Aff will look at the filename from
the perspective of the normal Citadel directory, not #NETAREA. So, if
you use "relative" file names (like "..\hello.zip", etc), you'll have
to be careful. If you want to be smart, just use absolute file paths
(like "C:\PRODUCT\STUFF.ZIP").
All of the following lines up to the first blank line are the names
of systems the file should be sent to. Notice the format -- it's
"<system name> : 0". The reason for the ": 0" is that Citadel-86 will
actually use CtdlAff.Sys to remember the last time it sent the file on
to each system. As the days pass, the "0" you should write in there
will change to other numbers. They represent the date stamp of the
file last time you checked and sent it. Don't mess with those numbers
unless you know what you're doing (it's usually not necessary, anyways).
You can update CtdlAff.Sys anytime you like, deleting systems,
adding systems, adding whole new file forwarding specs. However, the
Aff utility itself cannot be run from within Citadel-86; the system must
be down. For that reason, and if you don't already, you may
want to consider putting together a #event of type external which will
cause Aff to be run on an appropriate basis. See INSTALL3.MAN for more
information.
-17-
VEXFIND.EXE
Vortex handling in Citadel-86 (that is, the detection of loops in
the network) is activated by placing +vortex on the command line of
CTDL. The VEXFIND utility allows the display of information concerning
the current vortex records.
Vexfind may be used in one of two modes. First, just the name may
be typed at the command line:
C>VEXFIND
This will result in all of the current names known to the vortex handler
to be printed to the console. The second mode is to place a system name
on the command line:
C>VEXFIND "C-86 Test System"
This allows the discovery of the index value associated with the named
system. This can be used in turn to delete corrupted vortex records.
The vortex records are the files named *.VEX in the #NETAREA directory.
Once the index is found, simply delete "<index>.vex".
And, unlike most other Citadel-86 utilities, this utility can be run
while in #NETAREA or from your standard Citadel directory, because it
doesn't need CtdlTabl.Sys if the vortex files (VORTEX.SYS) are in the
current directory.
-18-